Resolve dynamic border and outline colors against the view trait collection in Fabric - #57837
Open
JacquesLeupin wants to merge 1 commit into
Open
Conversation
meta-codesync Bot
pushed a commit
that referenced
this pull request
Aug 21, 2026
…dii (#58028) Summary: Fixes #57841. `outlineStyle: 'dotted'` and `'dashed'` render as solid on iOS. Android renders all three correctly, and the documented API lists all three values with no platform caveat. ### Root cause `-[RCTViewComponentView invalidateLayer]` draws the outline through one of two paths: - **Core Animation** — sets `_outlineLayer.borderWidth` / `.borderColor`. Cheap, but `CALayer` can only stroke a *solid* border. - **Core Graphics** — `RCTAddContourEffectToLayer`, which forwards `outlineStyle` to `RCTGetBorderImage` and does honour dotted/dashed. The branch choosing between them only looked at the border radii: ```objc if (areBorderRadiiCircular(borderMetrics.borderRadii) && borderMetrics.borderRadii.topLeft.horizontal == 0) { ``` Every view **without a border radius** therefore took the Core Animation path, and its `outlineStyle` was silently dropped. Rounded views fell through to Core Graphics — which is why a dotted or dashed outline starts working as soon as a `borderRadius` is set. The equivalent branch for *borders*, ~80 lines above, already gets this right: `useCoreAnimationBorderRendering` includes `borderMetrics.borderStyles.left == BorderStyle::Solid`, so a non-solid border falls through to Core Graphics. The outline branch never got the matching check when `outline` was implemented in #46444. ### Fix Add the missing `outlineStyle == OutlineStyle::Solid` term, so non-solid outlines fall through to Core Graphics exactly as non-solid borders already do. Solid outlines keep the cheaper Core Animation path, so there is no cost for the common case. ### Why it went unnoticed The only RNTester examples using `outlineStyle: 'dotted'` / `'dashed'` also set a `borderRadius`, so they only ever exercised the working path. This PR adds the square-cornered cases next to them, labelled, so all six combinations of `{square, rounded} × {solid, dashed, dotted}` are visible at once. ### Note on #57837 #57837 (open) rewrites the two `UIColor *outlineColor = ...` lines in this same block to resolve dynamic colors against the trait collection. This change deliberately leaves those two lines untouched — it only adds a term to the surrounding `if` — so the two patches touch disjoint lines and should merge without conflict in either order. ## Changelog: [IOS] [FIXED] - Render `outlineStyle: 'dotted'` and `'dashed'` on views without border radii Pull Request resolved: #58028 Test Plan: ### Manual verification RNTester → Components → View → Outline, iPhone 17 Pro Simulator (iOS 26.1), New Architecture, built from source (`RCT_USE_PREBUILT_RNCORE=0`). | Before | After | | --- | --- | | <img src="https://raw.githubusercontent.com/neutronm/react-native/960889bd70d6cb18839f9d3586690908b0d8207d/assets/57841/before.png" width="420"> | <img src="https://raw.githubusercontent.com/neutronm/react-native/960889bd70d6cb18839f9d3586690908b0d8207d/assets/57841/after.png" width="420"> | | `square dashed` and `square dotted` render solid | all six render correctly | The rounded cases and every pre-existing example in the Outline screen are pixel-identical before and after; only the two square non-solid outlines change. ### Automated | Command | Result | | --- | --- | | `yarn jest` | 222/223 suites, 5713 tests pass | | `yarn flow-check` | `Found 0 errors` | | `yarn lint` (`eslint --max-warnings 0 .`) | clean | | `node ./scripts/clang-format.js <changed .mm files>` | no changes | | `yarn build-types --validate` | `PASS API snapshot is up to date.` | | `tsc -p packages/react-native/__typetests__/tsconfig.json` | clean | | `yarn test-ios` (`RNTesterUnitTests`) | `** TEST SUCCEEDED **` — 167 tests, 16 skipped, 0 failures | The one Jest suite that did not pass in the full run (`GenerateComponentDescriptorH-test.js`) was a worker `SIGSEGV`, not an assertion failure; it passes 18/18 when run on its own. ### Unit tests `React/Tests/Mounting/RCTViewComponentViewTests.mm` gains two cases next to the existing ones: - `testSquareSolidOutlineUsesCoreAnimationBorder` — a square solid outline still uses `CALayer.borderWidth` (the fast path is not regressed). - `testSquareDottedAndDashedOutlinesAreDrawnWithCoreGraphics` — square dotted and dashed outlines are drawn into `layer.contents` with `borderWidth == 0`. `React/Tests/**` is excluded from the `React-Core` podspec, so these are not built by the OSS `RNTesterUnitTests` target. They were verified to compile against the installed pod headers with `clang -fsyntax-only -x objective-c++ -std=c++20`. Reviewed By: cipolleschi Differential Revision: D116779403 Pulled By: javache fbshipit-source-id: b8d1f3508418016252ec9b1f9aaab7107c8f3b9f
JacquesLeupin
force-pushed
the
fix/fabric-dynamic-border-color-trait-collection
branch
from
August 21, 2026 19:19
3f025de to
8ff2463
Compare
Author
|
Rebased onto current main after #58028 landed. The only conflict was the adjacent outline fast-path guard; the resolution preserves #58028’s OutlineStyle::Solid condition and this PR’s trait-collection color resolution in both outline paths. The newly triggered Test All and Validate C++ API Snapshots runs are action_required with no jobs or logs, so they appear to be awaiting external-fork workflow approval rather than failing. Could someone with write access approve them when convenient? The PR includes a runnable RNTester reproducer and before/after test plan. I also added a focused XCTest that forces ambient-light traits with a dark view trait collection and asserts that the direct border and outline layers resolve the dark color variant. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #57836.
On Fabric,
borderColorandoutlineColorset from a dynamic color (PlatformColor/DynamicColorIOS) are converted toCGColorwithout an explicit trait-collection resolve, so they resolve againstUITraitCollection.currentTraitCollection— the system appearance. When the app's effective appearance differs from the system (Appearance.setColorScheme(...)/overrideUserInterfaceStyle), borders render the wrong variant, and views mounted while already attached under the override never get atraitCollectionDidChange:to heal them, so the wrong color persists.backgroundColoris unaffected becauseinvalidateLayeralready resolves it againstself.traitCollection; Paper is unaffected becauseRCTViewresolves border colors against the view's trait collection indisplayLayer:.This change applies the same treatment to the remaining color conversions in
invalidateLayer:layer.borderColor),RCTCreateRCTBorderColorsFromBorderColors(the border-image path), which now takes the view's trait collection,outlineColorpaths.Colors resolved with
resolvedColorWithTraitCollection:are static, so the existingtraitCollectionDidChange:→invalidateLayerhook keeps them correct when the effective appearance changes.layer.shadowColor(inupdateProps) shares the same latent flattening and could get the same treatment in a follow-up.Changelog:
[IOS] [FIXED] - Fabric: resolve dynamic (PlatformColor/DynamicColorIOS) border and outline colors against the view's trait collection instead of the system appearance
Test Plan
Runnable single-file RNTester reproducer for the issue: main...JacquesLeupin:react-native:repro/fabric-border-trait-collection-57836 (edits only
RNTesterPlayground.js). Equivalently, the reproducer from the linked issue as a stocknpx @react-native-community/cli initapp (New Architecture, iOS Simulator with system Light): oneDynamicColorIOS({light: red, dark: green})feeds a fill, a border on the border-image path, and a border on the CoreAnimation path; the app forces dark viaAppearance.setColorScheme('dark'), then mounts a second set of boxes under the override.invalidateLayer, but the conversion reads the ambient trait state. Recycled views reattached under the override stick the same way (no trait change at all).node_modules/react-nativeand rebuilt): every fill and border renders green, including the pre-override views once the trait-change invalidation runs against the view's own trait collection.Also verified as a patch on a production 0.81.5 New-Architecture app that applies its theme via
overrideUserInterfaceStyleat launch, where everyPlatformColorborder previously rendered the system variant: borders now follow the app theme across launch-time override, runtime toggles, and recycled list views;React-RCTFabriccompiles with no new warnings.